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PATENT 

IN THE UNITED STATES PATENT AND TRADEMARK OFFICE 
In re application of: 
Cowieet al. 
Application No. 1 0/003,322 
Filed: 12/06/2001 

For: INITIATING EXECUTION OF A 

COMPUTER PROGRAM FROM AN 
ENCRYPTED VERSION OF A. 
COM PUT BR PROGRAM 



Commissioner for Patents 
P.O. Box 1450 
Alexandria, VA 22313-1450 

ATTENTION: Board of Patent Appeals and Interferences 

SUBSTITUTE APPEAL BRIEF (37 C.F.R. § 41.37) 

This brief is in furtherance of the Notice of Appeal, filed in this case on 1 1/30/2006, a substitute 
for the Appeal Brief filed 01/30/2007, and in response to the Notification of Non-Compliant 
Appeal Brief mailed on 06/13/2007 (see attached). While appellant disagrees with the Examiner 
as to whether the alleged deficiencies exist in the original Appeal Brief a Substitute Appeal 
Brief with appropriate edits is nevertheless submitted to expedite prosecution. 

The fees required under § LI 7, and any required petition for extension of time for filing this 
brief and fees therefor, are dealt with in the accompanying TRANSMI TTAL OF APPEAL 
BRIEF. 

This brief contains these items under the following headings, and in the order set forth below (37 
C.F.R. §4 1.37(c)(1)): 

I REAL PARTY IN INTEREST 

II RELATED APPEALS AND INTERFERENCES 



Group Art Unit: 2131 
Examiner: Z1A, SYED 
Date: July 13, 2007 



HI STATUS OF CLAIMS 

IV STATUS OF AMENDMENTS 

V SUMM ARY OF CLAIMED SUBJECT MATTER 

VI GROUNDS OF REJECTION TO BE REVIEWED ON APPEAL 

VII ARGUMENT 

VI0 CLAIMS APPENDIX 

IX EVIDENCE APPENDIX 

X RELATED PROCEEDING APPENDIX 



The final page of this brief bears the practitioner's signature. 
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I REAL PARTY IN INTEREST (37 C.F.R. § 4l.37(c)(lKi)) 

The reai party in interest in this appeal is McAfee, Inc. 
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II RELATED APPEALS AND INTERFERENCES (37 C.F.R. § 41.37(c) (!)<«)) 

With respect to other prior or pending appeals, interferences, or related judicial proceedings that 
will directly affect, or be directly affected by, or have a bearing on the Board's decision in the 
pending appeal, there are no other such appeals, interferences, or related judicial proceedings. 

A Related Proceedings Appendix is appended hereto. 
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[II STATUS OF CLAIMS (37 C.F.R. § 41.37(c) (!)(»«)) 

A. TOTAL N UMBER OF CLAIMS IN APPLICATION 

Claims in the application are: 1-4, 9-16, 21-28, and 33-39 

B. STATUS OF ALL TH E CLAIMS IN APPLICATION 

I . Claims withdrawn from consideration: None 

2 Claims pending: 1-4, 9-16, 21-28, and 33-39 

3. Claims allowed: None 

4. Claims rejected: 1-4, 9-16, 21-28, and 33-39 

5 . Claims cancelled. 5-8, ] 7-20, and 29-32 

C. CLAIMS ON APPEAL 

The claims on appeal, are: 1-4, 9-16, 21-28, and 33-39 



See additional status information in the Appendix of Claims. 
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IV STATUS OF AMENDMENTS (37 C.F.R, § 41.37(c)(l ){iv)) 

As to the status of any amendment filed subsequent to final rejection, there are no such 
amendments after final . 
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V SUMMARY OF CLAIMED SUBJECT MATTER (37 C.F.R. § 41.37(c)(l)(v» 

With respect to a summary of Claim 1, as shown in Figure 1, a computer program product for 
controlling a computer to execute a computer program within a computer memory is provided. 
The computer program product comprises a loader program (e.g. see item 2 of Figure I, etc.) and 
an encrypted version of the computer program (e.g. see item 6 of Figure 1, etc.). The loader 
program (e.g. see item 2 of Figure 1, etc.) is operable to read the encrypted version of the 
computer program (e.g. see item 6 of Figure 1, etc.) stored in a program store, decrypt the 
encrypted version of the computer program (e.g. see item 6 of Figure 1, etc.) to form the 
computer program in an executable form (e.g. see item 9 of Figure 1, etc.), load the computer 
program (e.g. see item 9 of Figure I, etc.) directly into the computer memory (e.g. see item 8 of 
Figure 1, etc.), and trigger execution of the computer program (e.g. see item 9 of Figure 1, etc.) 
as loaded into the computer memory (e.g. see item 8 of Figure i, etc.) by the loader program 
(e.g. see item 2 of Figure 1, etc) The computer program (e.g. see item 9 of Figure 1, etc) that is 
decrypted, loaded, and executed includes a malware scanning computer program. Additionally, 
the malware scanning computer program is operable such that once executed, the malware 
scanning computer program scans the loader program (e.g. see item 2 of Figure 1, etc.) for 
malware. If the loader program (e.g. see item 2 of Figure 1, etc.) is detected as being infected 
with malware, then the malware scanning computer program is operable to repair the loader 
program (e.g. see item 2 of Figure 1, etc.) or replace the loader program (e.g. see item 2 of 
Figure 1, etc) with a. clean copy of the loader program (e.g. see item 2 of Figure 1, etc.). The 
malware scanning computer program is operable to scan for malware including one or more of a 
computer virus, a worm, a Trojan, a banned computer tile, a banned word and a banned image. 
See, for example, page 3, lines 10-22; page 4, lines 26-32; page 5, lines 1-6; and page 5, lines 8- 
1 1 et al. 

With respect to & summary of Claim .10, as shown in Figure 3, the computer program product of 
Claim 1 is provided where said computer program is operable to terminate said loader program 
when said computer program is triggered to execute by said loader program (e.g. see item 24 of 
Figure 3, etc.). See, for example page 8, lines 10-1 1 et al. 
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Wsth respect, to a summary of Claim 11, the computer program product of Claim 1 is provided 
where said loader program is operable to load said computer program into a memory space 
within said computer memory separate from a memory space used by said loader program. See 
for example, page 6, lines 32-33 et al. 

With respect to a summary of Claim 13, as shown in Figure 1, a method of executing of a 
computer program within a computer memory is provided, in use, a loader program (e.g. see 
item 2 of Figure I, etc.) is executed. The loader program (e.g. see item 2 of Figure 1, etc.) 
operates to read an encrypted version of the computer program (e.g. see item 6 of Figure I, etc.) 
stored in a program store, decrypt the encrypted version of the computer program (e.g. see item 6 
of Figure 1 , etc.) to form the computer program in an executable form (e.g. see item 9 of Figure 
I, etc), load the computer program (e.g. see item 9 of Figure I , etc.) directly into the computer 
memory (e.g. see item 8 of Figure 1, etc.), and trigger execution of the computer program (e.g. 
see item 9 of Figure 1, etc.). In addition, the computer program (e.g. see item 9 of Figure 1, etc.) 
is executed as loaded into the computer memory (e.g. see item 8 of Figure 1, etc.) by the loader 
program (e.g. see item 2 of Figure L etc). The computer program (e.g. see item 9 of Figure I, 
etc.) that is decrypted, loaded, and executed includes a malvvare scanning computer program. 
Additionally, the malware scanning computer program is operable such that once executed, the 
malware scanning computer program scans the loader program (e.g. see item 2 of Figure 1, etc. ) 
for mal ware. If the loader program (e.g. see item 2 of Figure 1 , etc.) is detected as being infected 
with the malware, then the malware scanning computer program is operable to repair the loader 
program (e.g. see item 2 of Figure 1, etc.) or replace the loader program (e.g. see item 2 of 
Figure 1, etc.) with a clean copy of the loader program (e.g. see item 2 of Figure 1, etc.). 
Further, the malware scanning computer program is operable to scan for the malware including 
one or more of a computer virus, a worm, a Trojan, a banned computer file, a banned word and a 
banned image. See, for example, page 3, lines 10-22; page 4, lines 26-32; page 5, lines 1-6; and 
page 5. lines 8-1 1 et al. 

With respect to a summary of Claim 22, as shown in Figure 3, the method of Claim 13 is 
provided where said computer program terminates said loader program when said computer 
program is triggered to execute by said loader program (e.g. see item 24 of Figure 3, etc.). See, 
for example, page 8, lines 1 0-1.1 et a!. 
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With respect to a summary of Claim 23, the method of Claim 13 is provided where said loader 
program loads said computer program into a memory space within said computer memory 
separate from a memory space used by said loader program. See for example, page 6, lines 32- 
33etal. 

With respect to a summary of Claim 25, as shown in Figure I, an apparatus for executing a 
computer program within a computer memory' is provided. The apparatus comprises loader 
program logic (e.g. see item 2 of Figure 1, etc) and a program store operable to store an 
encrypted version of the computer program (e.g. see item 6 of Figure 1, etc.). The loader 
program logic (e.g. see item 2 of Figure 1, etc. ) is operable to read the encrypted version of the 
computer program (e.g. see item 6 of Figure 1, etc.) stored in the program store, decrypt the 
encrypted version of the computer program (e.g. see item 6 of Figure 1 , etc.) to form the 
computer program in an executable form (e g. see item 9 of Figure I, etc.), load the computer 
program (e.g. see item 9 of Figure I, etc.) directly into the computer memory (e.g. see item 8 of 
Figure 1, etc.), and trigger execution of the computer program (e.g. see item 9 of Figure 1, etc.) 
as loaded into the computer memory (e.g. see item 8 of Figure 1 , etc.) by the loader program 
(e.g. see item 2 of Figure 1 , etc.). Additionally, the computer program that is decrypted, loaded, 
and executed includes a malware scanning computer program. The malware scanning computer 
program is operable such that, once executed, the malware scanning computer program scans the 
loader program (e.g. see item 2 of Figure 1, etc.) for malware. If the loader program (e.g. see 
item. 2 of Figure 1, etc) is detected as being infected with the malware, then the malware 
scanning computer program is operable to repair the loader program (e.g. see item 2 of Figure L 
etc.) or replace the loader program (e.g. see item 2 of Figure 1. etc.) with a clean copy of the 
loader program (e.g. see item 2 of Figure i, etc.). Further, the malware scanning computer 
program is operable to scan for the malware including one or more of a computer virus, a worm, 
a Trojan, a banned computer file, a banned word and a banned image. See, for example, page 3, 
lines 10-22; page 4, lines 26-32; page 5, lines 1-6; and page 5, lines 8-1 1 et al. 

With respect to a summary of Claim 34, as shown in Figure 3, the apparatus of Claim 25 is 
provided where said computer program logic is operable to terminate said loader program when 
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said computer program is triggered to execute by said loader program (e.g. see item 24 of Figure 
3, etc). See, for example, page 8, lines 10- J 1 et aL 

With respect to a summary of Clai m 35, the apparatus of Claim 25 is provided where said loader 
program logic is operable to ioad said computer program into a memory space within said 
computer memory separate from a memory space used by said loader program logic. See for 
example, page 6, lines 32-33 et al, 

With respect to a summary of Claim 37, as shown in Figure 3, the computer program product of 
Claim 1 is provided where, as a first task; said malware scanning computer program scans said 
loader program for said mal ware (e.g. item 28 of Figure 3, etc.). See, for example, page 8, lines 
17-19 etal. 

With respect to a summary of Claim 38, as shown in Figure 3, the computer program product of 
Claim 1 is provided where, if said loader program is detected as being infected with said 
malware, then said malware scanning computer program is operable to replace said loader 
program with a cl ean copy of said loader program (e.g. items 30 and 32 of Figure 3, etc.). See, 
for example, page 8, lines 19-23 et al. 

With respect to a summary of Claim 39, the computer program product of Claim 1 is provided 
where, if said loader program is detected as being infected with said malware, then said malware 
scanning computer program is operable to repair said loader program (e.g. items 30 and 32 of 
Figure 3, etc.) See, for example, page 8, lines 19-23 et al. 

Of course, the above citations merely provide examples of various claim language and possibly 
other features, and thus should not be construed as limiting in any manner. 
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VI GROUNDS OF REJECTION TO BE REVIEWED ON APPEAL (37 C.F.R. § 
4l.37(c)(l)<vi)) 

Following, under each issue listed, is a concise statement setting forth the corresponding ground 
of rejection. 

Issue # 1: The Examiner has rejected Claims 1-4, 9-16, 21-28, and 33-39 under 35 U.S.C, 103(a) 
as being unpatentable over Abu-Husein (U.S. Patent No. 6,895,506), in view of Nachenberg 
(U.S. Patent No. 5,826,013). 
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VII ARGUMENT (37 C.F.R. § 41.37(c)(I)(vii» 

The claims of the groups noted below do not stand or fail together. In the present section, 
appellant explains why the claims of each group are believed to be separately patentable. 

Issue # 1 : 

The Examiner has rejected Claims 1-4, 9-16, 21-28, and 33-39 under 35 U.S.C. 103(a) as being 
unpatentable over Abu-Husein (U.S. Patent No. 6,895,506), in view of Nachenberg (U.S. Patent 
No. 5,826,013). 

Group 41: Claims 1-4, 9, 12-16, 21, 24-28, 33, and 36 

With respect to the independent claims, the Examiner has relied on the following excerpt from 
the Nachenberg reference to make a prior art showing of appellant's claimed technique "wherein 
said computer program that is decrypted, loaded, and executed includes a ma! ware scanning 
computer program." 

"The present invention is a polymorphic anti-virus module or PAM {200,5 
for detecting polymorphic viruses {150) using mutation- engine specific 
information for each known polymorphic virus rather than heuristic 
stopper and booster code sequences . The PAM system (200) comprises a 
CPU emulator (210) for emulating the target program, a virus signature 
scanning module (250) for scanning decrypted virus code, and an 
emulation control module (220) , including a static exclusion module 
(230) and a dynamic exclusion module (240) , for determining how long 
each target file is emulated before it is scanned. The emulation 
control module (220) also includes dates (222} specific to each known 
polymorphic virus -ISO! and organised in a format that facilitates 
comparison with target files being tested for infection. This data 
(222} includes instruction/ interrupt usage profiles (224) for the 
mutation engines (1625 of the known polymorphic viruses (150;, as well 
as size and target file types (226} for these viruses. The emulation 
control module (220) also includes a table (228} having an entry for 
each known polymorphic virus (150) which can be flagged when 
characteristics inconsistent with the polymorphic virus are detected." 
(Col. 3, lines 3-24 - emphasis added) 

Appellant respectfully asserts diat the excerpt from Nachenberg relied upon by the Examiner 
merely teaches that the "[t]he PAM system (200) comprises a CPU emulator (210) for emulating 
the.target.prograni , a virus signature scanning module (250) for scanning Jecrypted.yirus code . 
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and an emulation control module (220), including a static exclusion module (230) and a dynamic 
exclusion module (240), for determining how long each target file is emulated before it is 
scanned" (Col. 3, lines 6-12 - emphasis added). However, " emulating the target program '' and 
^ scanning decrypted virus code " (emphasis added), as in Nachenberg, does not disclose a 
technique "wherein said computer program ..that. is decrypted, loaded, and executed includes... a 
ma! ware scanni ng computer program" (emphasis added) as claimed by appellant. Clearly, 
scanning decrypted virus code simply, as in Nachenberg, fails to even suggest a " ma! ware 
scanning computer program" that is "decrypted, loaded, and executed" (emphasis added), in the 
manner as claimed by appellant. 



Further, with respect to the independent claims, the Examiner has relied on the following excerpt 
from the Nachenberg reference to make a prior art showing of appellant's claimed technique 
"wherein said malware scanning computer program is operable such that once executed, said 
malware scanning computer program scans said loader program for ma!ware." 



*In accordance with the present invention, the static exclusion module 
(230) examines the gross characteristics of the target file for 
attributes that are inconsistent with the imitation engine specific data 
for known polymorphic viruses (150) , These characteristics are the type 
of target file, the size of the target file's load image, the presence 
of certain instructions at the file entry point, and the distance 
between the file entry point and the end of the load image. The last 
characteristic is; useful because most viruses append themselves to the 
files they infect. In some cases, the static exclusion module {230} 
allows certain target files to be identified as infected without any 
emulation. 

The dynamic exclusion module (240? examines the instruction/ interrupt 
usage profiles (224) of each known polymorphic virus (150) as each 
instruction is fetched for emulation. The instruction/interrupt usage 
profiles (224) indicate which polymorphic viruses (150) employ mutation 
engines that do not use the fetched instruction in decryption loops 
they generate, and the emulation control module (220} flags these 
viruses. The emulation control module (220) continues until ail 
mutation engines have been flagged or until a threshold number of 
instructions have been emulated. The flagging technique implemented by 
the dynamic exclusion module (240) determines when emulation has 
proceeded to a point where at least some code from the decrypted static 
virus foody (160} may be scanned and substantially reduces the number of 
instructions emulated prior to scanning the remaining target files 
without resort to booster or .stopper heuristics." (Col. 3, lines 25-53 
- emphasis added; 



- 14- 



Appellant respectfully asserts that the excerpt from Nachenberg relied upon by the Examiner 
merely discloses that "the static exclusion module (230) examines the gross characteristics of the 
target file for attributes that are inconsistent with the mutation engine specific data for known 
polymorphic viruses" (Col. 3, lines 25-28). In addition, Nachenberg discloses that "at least some 
code from the decrypted static virus body (160) may be scanned" (Col. 3, lines 49-50). Clearly, 
teaching the examination of the target file for attributes that are inconsistent with the mutation 
engine speci fic, data for known polymorphic viruses and that some code of decrypted static vims 
body may be scanned, as in Nachenberg, clearly fails to even suggest a technique "wherein said 
malware scanning computer program is operable such that once.exccuted.. said maj vvart .scanning 
computer program, scans said .loader program. for .maKyare'' (emphasis added), as claimed by 
appellant. 

In the Office Action dated 09/06/2006, the Examiner argued that "[a]n emulation control module 
includes a static exclusion module, a dynamic exclusion module, instruction/interrupt usage 
profiles for the mutation engines of the known polymorphic viruses, size and target file types for 
the viruses, and a table having an entry for each known polymorphic, vims" and that "[a]s a 
result, cited prior art does implement and teach a system and method that relates to scanning 
computer code for viruses and for providing results pertaining to the viruses found by scanning 
of the initiation of execution of a computer program using a mechanism that seeks to protect the 
computer program from malicious alteration" (see Page 3). 

Appellant respectfully disagrees with the Examiner's arguments and asserts that Nachenberg 
merely discloses that "(tjhe PAM system (200) comprises a CPU emulator (210) for emulating 
the target program, a virus signature scanning module (250) for scanning decrypted vims code, 
and an emulation control module (220), including a static exclusion module (230) and a dynamic 
exclusion module (240), for determining how long each target file is..emulated....before 
.scanned " (Col. 3. lines 7-13 - emphasis added). Further, Nachenberg discloses that "[ojnee the 
emulation phase has been terminated, scanning can begin on decrypted static virus body 160 or 
at least those parts decrypted by the first 1.5 million instructions" (Col. 9, lines 50-52 emphasis 
added). 
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However, merely disclosing scanning the decrypted static virus body once an emulation phase is 
terminated, as in Nachenberg, simply talis to even suggest a technique "wherein said maiware 
scanning computer program is operable such that onee_e^cuted T said maiware scanning 
computer program scans said loader program for maiware" (emphasis added), as claimed by 
appellant. Clearly, a system in which instructions of a target program are emulated before the 
target program is scanned, as m Nachenberg, fails to meet and even teaches away from a 
technique where ""said maiware scanning computer program is operable such that once executed, 
said maiware scanning computer program scans said loader program for maiware" (emphasis 
added), in the manner as claimed by appellant. 



In addition, with respect to the independent claims, the Examiner has relied on the following 
excerpt from the Nachenberg reference to make a prior art showing of appellant's claimed 
technique "wherein, if said loader program is detected as being infected with said maiware, then 
said maiware scanning computer program is operable to repair said loader program or replace 
said loader program with a clean copy of said loader program;' 



"Once the emulation phase has been terminated, scanning can begin on 
decrypted static virus foody 160 or. at least those parts decrypted by 
the first 1.5 million instructions. In order to facilitate scanning of 
static virus body 160, emulation control module 22 0 keeps track of 
which locations of virtual memory are most likely to be infected. In 
particular, emulation control module 220 tags the page or pages of 
virtual memory containing an. instruction executed by ssnuia!;or 210. In 
addition, every time an emulated instruction writes to memory, the 
altered pages are tagged as containing modified data. Tagged pages in 
virtual memory are scanned for signatures of static virus body 160 as 
follows : 

ill if a page contains executed code, it and the following page are 
scanned 

(2) if a page has been written to during emulation and more than a 
threshold number of memory writes occurred anywhere in memory during 
emulation, the modified page and the following page are scanned." {Col. 
9, lines 50-67 - emphasis added) 

Appellant respectfully asserts that the excerpt from Nachenberg relied upon by the Examiner 
merely discloses that "every time an emulated instruction writes to memory, the altered pages are 
tagged as containing modified data.*' Further, Nachenberg teaches that "[flagged pages in virtual 
memory are scanned for signatures of static virus body." However, merely scanning tagged 
pages in virtual memory, as in Nachenberg, fails to even suggest a technique "wherein, if said 
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loader program is detected as being infected with said malware, then said malware scanning 
computer pro^ 

a cjean copy of said joader Program" (emphasis added), as claimed by appellant. 

In the Office Action dated 09/06/2006, the Examiner argued that "[ijhe computer virus detection 
module includes a CPU emulator for emulating a target program, and a virus signature scanning 
module for scanning decrypted virus code" (see Page 3). However, appellant respectfully asserts 
that merely "'scanning [the] static virusjody" and scanning "[flagged pages in virtual 
memory... for signatures of [a] static virus body" (emphasis added), as in Nachenberg, does not 
even suggest a program operable to repair said loader program or replace said loader program 
with a clean copy of said loader program" (emphasis added), in the manner as claimed by 
appellant. Further, appellant respectfully asserts that Nachenberg merely discloses that "[i]n 
order to return control of the computer to program code 120 following execution of virus 130, 
CS, IP, SS, and SP of uninfected image .100 are retained by virus 130" (Col. 5, lines 36-39 - 
emphasis added), Clearly, die virus retaining uninfected fields in order to return control after the 
execution of the virus, as in Nachenberg, simply fails to even suggest a program "operable to 
repair said loader program or replace said loader program with a clean copy of said loader 
program" (emphasis added), in the manner as claimed by appellant. 

To establish a prima facie case of obviousness, three basic criteria must be met. First, there must 
be some suggestion or motivation, either in the references themselves or in the knowledge 
generally available to one of ordinary skill in the art, to modify the reference or to combine 
reference teachings. Second, there must be a reasonable expectation of success. Finally, the prior 
art reference (or references when combined) must teach or suggest all the claim limitations. The 
teaching or suggestion to make the claimed combination and the reasonable expectation of 
success must both be found in the prior art. and not based on appellant's disclosure. In re 
Vaeck,941 F.2d 488, 20 USPQ2d 1438 (Fed.Cir.1991). 

Appellant respectfully asserts that at least the third element of the prima facie case of 
obviousness has not been met, since the prior art references, when combined, tail to teach or 
suggest all of the clai m limitations, as noted above. 
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Groitp 02: Claims 10, 22, and 34 



With respect to Claim 10 et al., the Examiner has relied on the following excerpt from the Abu- 
Husein reference to make a prior art showing of appellant's claimed technique "wherein said 
computer program is operable to terminate said loader program when said computer program is 
triggered to execute by said loader program" (see the same, or similar language, in each of the 
aforementi oned claims) . 



"Finally, it must be noted that, as well understood by those of 
ordinary skill in the relevant: >srts, the execution of « Process: 16 in 
or by a PU 12 is conducted in an operating environment that is 
generally referred to as a "context". The context in which a Process 16 
is executed includes, for example, the current operating state of the 
system, the current execution state of the Process 16 and the program 
the Process 16 is executing, and so on. In general, and typically, each 
Process 16 is executed in a corresponding context and the execution of 
a different Process 16 involves or requires a change of the system 

16. Such changes in context, which are often referred to as "context 
switches" or "context swaps", may occur, for example, when a Process 16 
must call another Process 16 for an operation or has been completed or 
when the processor "time slice" allocated to a Process 16 has ended and 
the processor is to be allocated, to the execution of a different 
Process IS " (Col. 8. line fro - Col. 9, ?.ine ii> - emphases added; 

Appellant respectfully asserts that the excerpt from Abu-Husein relied upon by the Examiner 
merely discloses that '"context switches" ... may occur ... when a Process 16 mast call another 
Process 16 for an operation or has been completed or when the processor "time slice" allocated 
to a Process 16 has ended and the processor is to be allocated to the execution of a different 
Process 16' (Col. 9, lines 10-15 - emphasis added). Clearly, the concept of " time slices " and 
"context switches/' (emphasis added), as in Abu-Husem, simply fails to even suggest a technique 
"wherein said computer program is operable to terminate said loader program when said 
computer program is triggered to execute by said loader program " (emphasis added), as claimed 
by appellant. 



In the Office Action dated 09/06/2006, the Examiner tailed to specifically respond to appellant's 
arguments and simply dismissed them as non-persuasive. Appellant emphasizes that Abo- 
Husein discloses that "(djuring a context switch, the execution of the currently executing Process 
1 6 is suspended and the storage space in Memory 12C is reassigned by the Memory Manager 
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30A to accommodate the programs and data of the new Process 16" (Col. 9, lines 16-19 - 
emphasis added). Clearly, Abu-Husein's disclosure that the currently executing process is 
suspended during a context switch, simply fails to even suggest that the "computer program is 
operable to terminate said loader program when said computer program is triggered to execute 
by said loader program" (emphasis added), in the manner as claimed by appellant. 



Again, appellant respectfully asserts that at least the third element of the prima facie ease of 
obviousness has not been met, since the prior art references, when combined, fail to teach or 
suggest all of the claim l imitations, as noted above. 



Group &3: Claims //, 23, and 35 



With respect to Claim 1 1 et al., the Examiner has relied on the following excerpt from the Abu- 
Husein reference to make a prior art showing of appellant's claimed technique "wherein said 
loader program is operable to load said computer program into a memory space within said 
computer memory separate from a memory' space used by said loader program" (see the same, or 
similar language, in each of the aforementioned claims). 



* During a context switch, the execution of the currently executing 
Process IS is suspended and the storage space in Memory 12C is 
reassigned by the Memory Manager 30A to accommodate the programs and 
data of the new Process 16, thereby requiring that the context of the 
current Process 16 be saved to allow the execution of the Process 16 to 
be resumed at the point it was suspended when the Process 16 is 
"switched" or "swapped" in and again becomes the Process IS currently 
being executed. The saving and return of context state is typically 
performed by a Contest Switch Mechanism 30C that operates co- 
operatively with the Memory Manage;: 3 OA and that maintains and manages 

and is used to store the essential context, information, identified in 

relevant arts, a Context: Memory SOD may be implemented in a number of 
structures and formats and the context information may include, for 
example, the state of execution of a program being executed by the 
Process 16, data being generated as a result, of the Process 1.6 
operations, and so on. 

In the presently preferred embodiment of the present invention, and in 
those embodiments requiring provision for context switching, the 
Context. Switch Mechanism 30C is modified to include at least the Header 
18H of a Program 18 among the Context State 30E elements stored in 
Context Memory 300 when the Process 16 in which the Program 18 is being 
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DJitext switched. Context Switch Mechanism. 30C than returns 
H to Memory 12C when the Process 16 in which the Program 
executed is returned or restored for execution, and the 
■e Process 18 is correspondingly returned, so that Header 
labia to Load/Decrypt 28 during continuation of the 
:h« Program 18." {Col. 9, lines 16-50 - emphasis added) 

Appellant respectfully asserts that excerpt from Abu-Husein relied upon by the Examiner merely 
discloses a method of performing a "context switch." Specifically, Abu-Husein discloses a 
context switch where "the execution of the currently executing Process 16 is suspended and the 
storage space in Memory 12C is reassigned by the Memory Manager 30A to accommodate the 
programs and data of the new Process 16." 

Additionally, Abu-Husein teaches that the context of the current process is saved k to allow the 
execution of the Process 16 to be resumed at the point it was suspended when the Process 16 is 
"switched" or "swapped" in and again becomes the Process 16 currently being executed.' 
However, merely disclosing a context switch, as in Abu-Husein, fails to even suggest a technique 
"wherein said . loader program is operable to load s aid computer pr ogram into a memory space 
within said computer memory separate from a memory space used by said loader program " 
(emphasis added), as claimed by appellant. 

In the Office Action dated 09/06/2006, the Examiner failed to specifically respond to appellant's 
arguments and simply dismissed them as non-persuasive. Appellant emphasizes that Abu- 
Husein merely discloses that " Program . tpader/pe^ 

which may be implemented, for example, as a program controlled Process 1.6 executed by 
Processor J2.A" (Col. 6, lines 53-57 - emphasis added). Further, Abu-Husein discloses that 
" LoM/Decrypt .28 is similar to a conventional loading utility in responding to calls, commands or 
requests for the execution of a program or a program module or function by operating in 
conjunction ..with, a .Mem ory... Manager 30 A to read the corresponding program code from Storage 
12E and to write the program code , into M.ot at locations selected and managed by 

Memory Manager 30A for execution by Processor 1 : 2A" (Col. 6, lines 60-67 - emphasis added). 

However, the disclosure that the Load/Decrypt, which is a program controlled process executed 
by the Processor, operates in conjunction with Memory Manager to read the code from Storage 
and write the code into Memory for execution by the Processor, as in Abu-Husein, clearly fails to 
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even suggest, a technique "wherein said loader program is operable to load said computer 
program mto..a..niempff,, space within said computer memory separate from a memory space 
»j>M.by.Mj4.]iQ^g.^1?:rog^anl. , ' (emphasis added), as claimed by appellant. 

Again, appellant respectfully asserts that at least the third element of the prima facie case of 
obviousness has not been met, since the prior art references, when combined, foil to teach or 
suggest all of the claim limitations, as noted above. 

Group #4: Claim 37 

With respect to dependent Claim 37, the Examiner has relied on Col. 3, lines 25-53 from the 
Nachenberg reference (reproduced above) to make a prior art showing of appellant's claimed 
technique "wherein, as a first task, said mahvare scanning computer program scans said loader 
program for said malware." 

Appellant respectfully points out that the excerpt relied on by the Examiner merely teaches that 
"the static exclusion module (230) examines the gross characteristics of the target file for 
attributes that are inconsistent with the mutation engine specific data for known polymorphic 
viruses" (Col 3, lines 25-28) and that "[fjhe emujatipn.cont^ (220) continues until all 

mutation engines have been flagged or until a threshold number of instructions have been 
emulated" (Col. 3, lines 44-46 - emphasis added). However, examining characteristics of a 
target file and emulating intrusions, as in Nachenberg, does not teach scanning a loader program , 
much less a specific technique "wherein, as a first task , said malware scanning computer 
program scans said loader program for said malware" (emphasis added), as claimed by appellant. 

Again, appellant respectfully asserts that. at. least, the third element of the prima facie case of 
obviousness has not been met, since the prior art references, when combined, fail to teach or 
suggest all of the clai m l imitations, as noted above. 

Group MS: Claim 38 
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With respect to dependent Claim 38, the Examiner has relied on Col. 9, lines 50-67 (reproduced 
above), in addition to the excerpt below, from the Nachenberg reference to make a prior art 
showing of appellants claimed technique "wherein, if said loader program is detected as being 
infected with said malware, then said malware scanning computer program is operable to replace 
said loader program with a clean copy of said loader program." 

*Upon infection by corcsput^i: virus 130, header 110' of executable image 
100' is modified so that size field equals the size of executable image 
100 increrciented by the size o ■: corripiiter vi rus 130. In addition, 
computer virus 130 has replaced CS, IP of image 100 with CS' , IP' in 
image: 100'. CS' , IP' point to an entry point 132 of virus 130 rather 
than entry point 122 of program code 120. Similarly, computer virus 130 
has replaced SS, SP of image 100 with SS', SP' in image 100', which 
point to the end of virus 130. In order to return control of the 
computer to program code 120 following execution of virus 130, CS, IP, 
SS, and sp of uninfected image 100 are retained by virus 130." (Col, 5, 
lines 27-35 - emphasis added) 

Appellant respectfully asserts that the excerpts from Nachenberg relied upon by the Examiner 
merely disclose that "every lime an emulated instruction writes to memory, the altered pages are 
tagged as containing modified data" (Col. 9, lines 58-60) and that "jfjagged pages in virtual 
memory are scanned for signatures of static virus body" (Col, 9, lines 60-61). Further, 
Nachenberg discloses that, "[ujpon infection by computer virus 130... computer virus 130 has 
replaced CS [code segment Held], IP [instruction pointer Held] of image 1 00 with CS', IP' in 
image 100"' (Col. 5, lines 27-31 emphasis added) and that "[i]n order to return control of the 
computer to program code 120 following execution of virus 130, CS, IP. SS, and SP of 
uninfected image 100 are retained by virus 130" (Col. 5, lines 35-38 - emphasis added). 

However, appellant notes that teaching the scanning of tagged pages in virtual memory, in 
addition to disclosing that a computer viais replaces code segment and instruction pointer fields, 
and retains the iiistasction pointers in order to return control to the computer program, as in 
Nachenberg, fails to teach a technique "wherein, if said loader program is detected as being 
infected with said malware, then said malware scanning computer program is operable to replace 
said loader p ro gram with a clean copy of said loader program" (emphasis added), as claimed by 
appellant. Clearly, the virus retaining instruction pointers to the uninfected image, as in 
Nachenberg, fails to meet "said majware.scannijig.conipute^ is operable to replace jaM 
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loader program with a clean copy of said loader program'' (emphasis added), in the manner as 
claimed by appellant. 

Again, appellant respectfully asserts that at least the third element of the prima facie case of 
obviousness has not been met, since the prior art references, when combined, fail to teach or 
suggest all of the claim limitations, as noted above. 

Group ii-6: Claim 39 

With respect to dependent Claim 39, the Examiner has relied on Col. 9, lines 50-67, and Col. 5, 
lines 27-39 .from the Nachenberg reference (reproduced above) to make a prior art showing of 
appellant's claimed technique "wherein, if said loader program is detected as being infected with 
said malware, then said malware scanning computer program is operable to repair said loader 
program" 

Appellant respectfully asserts that the excerpts from Nachenberg relied upon by the Examiner 
merely disclose that "every time an emulated instruction writes to memory, the altered pages are 
tagged as containing modified data" (Col. 9, lines 58-60) and that "[fjagged pages in virtual, 
memory are scanned for signatures of static virus body" (Col. 9, lines 60-6.1). Further, 
Nachenberg discloses that "[u]pon infection by computer vims 130... computer virus 130 has 
replaced CS [code segment field], IP [instruction pointer field] of image 100 with CS\ IP' in 
image 100'" (Col 5, lines 27-31 - emphasis added) and that "[i]n order to return,comroj,,of the 
computer to program code 120 following execution of virus 130, CS, IP, SS, and SP of 
uninfected image 100 are retained by virus 130" (Col, 5, lines 35-38 - emphasis added). 

However, appellant respectfully asserts that that teaching the scanning of tagged pages in virtual 
memory, in addition to disclosing that a computer vims replaces code segment and instruction 
pointer fields and retains the instruction pointers in order to return control to the computer 
program, as in Nachenberg, fails to teach a technique "wherein, if said loader program is 
detected as being infected with said malware, then said malware scanning computer program is 
operable to repak.sa^ (emphasis added), as claimed by appellant. Clearly, the 

vims replacing code and instruction pointers, and retai mng the ..instruct! on poin ters to the 
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uninfected image, as in Nachenberg, fails to suggest that "said malware scanning computer 
proSfMl is operable to repair said loader program " (emphasis added), in the manner as claimed 
by appellant. 

Again, appellant respectfully asserts that at least the third element of the prima facie case of 
obviousness has not been met, since the prior art references, when combined, foil to teach or 
suggest aJl of the claim limitations, as noted above. 

In view of the remarks set. forth hereinabove, all of the independent claims are deemed 
allowable, along with any claims depending therefrom. 
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VIII CLAIMS APPENDIX (37 C.F.R. § 41.37(c)(l)(viii)) 

The text of the claims involved in the appeal (along with associated status information) is set 
forth below: 

.1 . (Previously Presented) A computer program product for controlling a computer to 
execute a computer program within a computer memory, said computer program product 
comprising; 

(a) a loader program; and 

(b) an encrypted version of said computer program; wherein said loader program is operable to: 

(1) read said encrypted version of said computer program stored in a program store; 
(a) decrypt said encrypted version of said computer program to form said computer 
program in an executable form; 

(Hi) load said computer program directly into said computer memory; and 

(iv) trigger execution of said computer program as loaded into said computer memory by 

said loader program; 

wherein said computer program thai is decrypted, loaded, and executed includes a 
malware scanning computer program; 

wherein said malware scanning computer program is operable such that once executed, 
said malware scanning computer program scans said loader program for malware; 

wherein, if said loader program is detected as being infected with said malware, then said 
malware scanning computer program is operable to repair said loader program or replace said 
loader program with a clean copy of said loader program; 

wherein said malware scanning computer program is operable to scan for said malware 
including one or more of a computer virus, a worm, a Trojan, a banned computer tile, a banned 
word and a banned image. 

2. (Original) A computer program product as claimed in claim I . wherein said encrypted 
version of sai d computer program is encrypted with a private encryption key and said loader 
program is operable to decrypt said encrypted version of said computer program with a 
corresponding public key. 
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3 . (Original) A computer program product as claimed in claim 1 , wherein said encrypted 
version of said computer program and said loader program are stored as separate computer files 
within a computer fiie store. 

4. (Original) A computer program product as claimed in claim I , wherein said loader 
program is associated with initialisation data specifying one or more of: 

a storage location of said encrypted version of said computer program; 
a key to be used in decrypting said encrypted version of said computer program; and 
parameters specifying how said computer program should be loaded into said computer 
memory for execution. 

5. (Cancelled) 

6. (Cancelled) 

7. (Cancelled) 

8. (Cancelled) 

9. (Original) A computer program product as claimed in claim 1 , wherein said loader 
program is operable to terminate after triggering execution of said computer program. 

10. (Original) A computer program product as claimed in claim 1, wherein said computer 
program is operable to terminate said loader program when said computer program is triggered 
to execute by said loader program. 

i 1 . (Original) A computer program product as claimed in claim 1 , wherein said loader 
program is operable to load said computer program into a memory space within said computer 
memory separate from a memory space used by said loader program. 



-26- 



1 2. (Original) A computer program product as claimed in claim 1 , wherein said loader 
program is operable to load said computer program into an execution stream separate from an 
execution stream used by said loader program. 

13, (Previously Presented) A method of executing of a computer program within a computer 
memory, said method comprising the steps of: 

(a) executing a loader program, said loader program operating to: 

(i) read an encrypted version of said computer program stored in a program store; 
(si) decrypt said encrypted version of said computer program to form said computer 
program in an executable form; 

(iti) load said computer program directly into said computer memory; and 
(iv) trigger execution of said computer program; and 

(b) executing said computer program as loaded into said computer memory by said loader 
program; 

wherein said computer program thai is decrypted, loaded, and executed includes a 
maiware scanning computer program, 

wherein said maiware scanning computer program is operable such that once executed, 
said maiware scanning computer program scans said loader program for maiware; 

wherein, if said loader program is detected as being infected with said maiware, then said 
maiware scanning computer program is operable to repair said loader program or replace said 
loader program with a clean copy of said loader program; 

wherein said maiware scanning computer program is operable to scan for said maiware 
including one or more of a computer virus, a worm, a Trojan, a banned computer file, a banned 
word and a banned image, 

14, (Original) A method as claimed in claim 13, wherein said encrypted version of said 
computer program is encrypted with a private encryption key and said loader program decrypts 
said encrypted version of said computer program with a corresponding public key. 

1 5. (Original) A. method as claimed in claim 13, wherein said encrypted version of said 
computer program and said loader program are stored as separate computer files within a 
computer file store. 



-27- 



16. (Original) A method as claimed in claim 1 3, wherein said loader program is associated 
with initialisation data specifying one or more of: 

a storage location of said encrypted version of said computer program; 
a key to be used in decrypting said encrypted version of said computer 
program; and 

parameters specifying how said computer program should be loaded into said computer 
memory for execution. 

17. (Cancelled) 

18. (Cancelled) 

19. (Cancelled) 

20. (Cancelled) 

21. (Original) A method as claimed in claim 13, wherein said loader program terminates after 
triggering execution of said computer programs. 

22. (Original) A method as claimed in claim 13, wherein said computer program terminates 
said loader program when said computer program is triggered to execute by said loader program. 

23. (Original ) A method as claimed in claim 13, wherein said loader program loads said 
computer program into a memory space within said computer memory separate from a memory 
space used by said loader program. 

24. (Original) A method as claimed in claim 1 3, wherein said loader program loads said 
computer program into an execution stream separate from art execution stream used by said 
loader program. 
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25. (Previously Presented) Apparatus for executing a computer program within a computer 
memory, said apparatus comprising: 

(a) loader program logic; and 

(b) a program store operabie to store an encrypted version of said computer program; wherein 
said loader program logic is operabie to. 

(i) read said encrypted version of said computer program stored in said program store; 

(ii) decrypt said encrypted version of said computer program to form said computer 
program in an executable form; 

(Hi) load said computer program directly into said computer memory, and 
(iv) trigger execution of said computer program as loaded into said computer memory by 
said loader program; 

wherein said computer program that is decrypted, loaded, and executed includes a 
malware scanning computer program; 

wherein said malware scanning computer program is operable such that once executed, 
said malware scanning computer program scans said loader program for malware; 

wherein, if said loader program is detected as being infected with said malware, then said 
malware scanning computer program is operable to repair said loader program or replace said 
loader program with a clean copy of said loader program; 

wherein said malware scanning computer program is operabie to scan for said malware 
including one or more of a computer virus, a worm, a Trojan, a banned computer file, a banned 
word and a banned image. 

26. (Original) Apparatus as claimed in claim 25, wherein said encrypted version of said 
computer program is encrypted with a private encryption key and said loader program logic is 
operable to decrypt said encrypted version of said computer program with a corresponding 
public key. 

27. (Original) Apparatus as claimed in claim 25, wherein said encrypted version of said 
computer program and said loader program are stored as separate computer files within a 
computer file store. 
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28. (Original) Apparatus as claimed in claim 25, wherein said loader program logic is 
associated with initialisation data specifying one or more of. 

a storage location of said encrypted version of said computer program; 
a key to be used in decrypting said encrypted version of said computer 
program; and 

parameters specifying how said computer program should be loaded into said computer 
memory for execution. 

29. (Cancelled) 

30. (Cancelled) 

31. (Cancelled) 

32. (Cancelled) 

33. (Original) Apparatus as claimed in claim 25, wherein said loader program logic is 
operable to terminate after triggering execution of said computer programs. 

34. (Original) Apparatus as claimed in claim 25, wherein said computer program logic is 
operable to terminate said loader program when said computer program is triggered to execute 
by said loader program. 

35. (Original) Apparatus as claimed in claim 25, wherein said loader program logic is 
operable to load said computer program into a memory space within said computer memory 
separate from a memory space used by said loader program logic, 

36. (Original) Apparatus as claimed in claim 25, wherein said loader program logic is 
operable to load said computer program into an execution stream separate from an execution 
stream used by said loader program, logic. 
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37. (Previously Presented) A computer program product as claimed in claim 1, wherein, as a 
first task, said mahvare scanning computer program scans said loader program for said mahvare. 

38. (Previously Presented) A computer program product as claimed in claim I , wherein, if 
said loader program is detected as being infected with said mahvare, then said mahvare scanning 
computer program is operable to replace said loader program with a clean copy of said loader 
program. 

39. (Previously Presented) A computer program product as claimed in claim I , wherein, if 
said loader program is detected as being infected with said malware, then said mahvare scanning 
computer program is operable to repair said loader program. 
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IX EVIDENCE APPENDIX (37 C.F.R. § 4l.37(c)(l)(ix)) 

There is no such evidence. 



X RELATED PROCEEDING APPENDIX (37 C.F.R. § 4I,37(c)(I)(x)) 

N/A 
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lo the event a telephone conversation would expedite the prosecution of this application, the 
Examiner may reach the undersigned at (408) 971-2573, For payment of any additional fees due 
in connection with the filing of this paper, the Commissioner is authorized to charge such fees to 
Deposit Account No. 50-1351 (Order No. NAI1P481). 



Respectfully submi tted, 



By: /KEVINZjI.KA/ Date: Jul vil 5 2007. 

Kevin 1. Zilka 
Reg. No. 41,429 

Zilka-Kotab, P C, 

P.O. Box 72 I I 20 

San Jose, California 95172-1120 

Telephone : (408) 97 1 -2 5 73 

Facsimi 1 e: (408) 97 1 -4660 
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